[00:08.680 --> 00:21.860]  Hello everyone. Today I'm going to be talking about Windows Kernel and how it's, from a security research perspective, how it changed in the past years and how we need to adapt.
[00:22.900 --> 00:32.160]  And so it will be mainly in the view of memory corruptions, not because I think that's most important, but just because I like them, as I like the Kernel and the risers.
[00:33.820 --> 00:43.320]  So, at first, we can start with a small introduction of who I am. I'm Peter Zierman. I'm working currently for KeyLab at Ensys.
[00:43.320 --> 00:57.820]  I'm a former team employee, a team member, and I was also ranked in MSS since 108 several times and also on 1.1 with my team, with our team several times, and this is my focus.
[00:57.820 --> 01:15.400]  It's on Windows Kernel. The risers, basically, are not too much about machine learning. It's understanding how it works, every kind of internals, but mainly about fuzzing and the machine learning to understand how to fuzz it in a good way.
[01:16.220 --> 01:22.580]  And also I like to apply the mitigations, understand them, correct them, and hopefully improve them.
[01:22.580 --> 01:30.660]  And also sometimes you can see me talking somewhere, for example, at home, or during the night, or somewhere else.
[01:31.000 --> 01:40.760]  And because I'm Chinese, I also like Wushu, but I don't particularly like it.
[01:41.800 --> 01:57.860]  So when it comes to security research and you ask somebody, some security researcher, to get code execution targets, first what comes to his mind is what is sandbox.
[01:59.160 --> 02:06.180]  It's basically some set of policies which tell you what you can and what you cannot do.
[02:06.180 --> 02:14.240]  For example, when you want to attack some target and get code execution into it, first you need to find a vulnerability.
[02:14.240 --> 02:17.900]  For this one, it's essential how easy it is to attack your place.
[02:17.900 --> 02:28.200]  But when your sandbox policies tell you that you are not allowed to call a lot of functionality, that means it's bad news for you.
[02:28.200 --> 02:34.280]  Because you have harder times to find a vulnerability because you don't have so many options.
[02:34.280 --> 02:41.020]  And on the other hand, even if you find a vulnerability, you may not be able to exploit it.
[02:41.020 --> 02:54.620]  Because exploitation and finding vulnerabilities, maybe you need to have two different resources, which overlap, but it can happen that you find a vulnerability but you cannot exploit it.
[02:54.620 --> 03:11.400]  And except for syscalls, I mean, also intactly depending on sys, everything about syscalls, but explicitly disabling some syscalls, it's very important to restrict those access to file system or registry.
[03:11.420 --> 03:22.760]  Because registry is basically configuration of your computer, and when you are able to configure someone else's computer to register you, and the same applies for file access.
[03:22.760 --> 03:31.340]  Basically, because when you are able to read and write any file on the user system, you won't anyway, because that's what you really want to do.
[03:31.860 --> 03:41.700]  And another thing is that it's really important to also restrict how some processes can communicate with some other processes.
[03:41.800 --> 03:44.660]  Why? And that's exactly because of sandbox.
[03:44.660 --> 03:50.080]  Because sandbox policies can restrict you to something, and it can be really restrictive in your targets.
[03:50.200 --> 04:03.680]  But when you can access different processes, then you may be able to escape and get code execution to the process, and that process has a less restricted sandbox.
[04:03.760 --> 04:09.940]  And you can access more on the surface and use more options how to call the system.
[04:10.920 --> 04:16.100]  And as I just mentioned, there are different kinds of sandboxes and different input levels.
[04:18.800 --> 04:21.240]  Less restrictive means more problems for you.
[04:22.160 --> 04:31.220]  But still, even when you have a sandbox, it can look like, okay, it can be... I mean, it's tougher, definitely, but it's not game over.
[04:31.220 --> 04:39.160]  Because still, for example, somebody develops an application, you want the targets.
[04:39.160 --> 04:43.600]  But that application essentially needs to interact with the system.
[04:43.740 --> 04:48.440]  For example, it may need to store some files on the disk.
[04:48.840 --> 04:57.140]  But this is dangerous, because even if sandbox allows you to store some files in some new directory just for you,
[04:57.140 --> 05:01.360]  there are some other entities, some other processes, which can scan this file.
[05:01.720 --> 05:06.040]  And as well, in this scanning process, there can be some vulnerabilities.
[05:06.040 --> 05:12.780]  And you can end up dropping files, and by that file you are dropping a different process, which is usually less restricted.
[05:13.880 --> 05:18.040]  And another thing, as I mentioned, is inter-process communication.
[05:19.760 --> 05:21.780]  Processes need to communicate.
[05:21.780 --> 05:28.660]  And especially with an application, it can be said, okay, I want to apply sandbox policies to this application.
[05:28.900 --> 05:32.460]  Because I know that, for example, some parts can just compute something,
[05:32.460 --> 05:38.040]  other parts may just pop up some nice windows and graphics,
[05:38.040 --> 05:40.540]  and some other parts doing some network communication.
[05:40.660 --> 05:47.120]  So for every part, I can have different sandboxes, and these can be different policies applied to different parts.
[05:47.120 --> 05:53.560]  Some of them can have restricted access to some parts, and some of them will be restricted to other parts.
[05:53.640 --> 05:58.880]  But at the end, all of them cooperate to achieve the same goal of the application.
[05:58.880 --> 06:00.940]  So they need somehow to communicate.
[06:01.360 --> 06:06.460]  And you can most likely also attack this infrastructure.
[06:06.700 --> 06:13.180]  That means when in your application, you communicate with other components, different processes in your application,
[06:13.180 --> 06:19.220]  but, for example, when in one application you cannot access, for example, certain syscalls,
[06:19.220 --> 06:25.940]  you may extend to the second process, which may be semi-technical at all,
[06:25.940 --> 06:29.860]  but there are some different restrictions, and it does have some limitations.
[06:30.200 --> 06:33.980]  It's a better background for you to start building exploits.
[06:35.320 --> 06:45.000]  And I said that Windows Kernel syscalls, but when you access any resource on machines, everything is about syscalls.
[06:47.440 --> 06:55.860]  So when it comes to Windows Kernel, I'm focusing on Windows Kernel, not because I think it's most important, but because I like it.
[06:56.120 --> 07:02.820]  And in the past, in fact, it was probably one of the most important parts, because all these sandbox policies
[07:04.240 --> 07:08.080]  not all, but a lot of crucial ones are decided in the kernel.
[07:08.080 --> 07:14.740]  So once you get some read-write in the kernel, with some control over the kernel, you can change the policy.
[07:16.000 --> 07:17.740]  And it's pretty neat.
[07:18.420 --> 07:23.240]  So when it comes to finding vulnerabilities and exploitation in kernel,
[07:23.240 --> 07:32.220]  then usually by sandboxes, for example, like C++, there are a few different categories of Windows Kernel,
[07:32.220 --> 07:33.980]  where you want to look for.
[07:33.980 --> 07:35.420]  It's top priority.
[07:35.640 --> 07:39.420]  I would suggest Swing. It's OK, because it's really huge.
[07:39.440 --> 07:46.240]  It's really old code, and I mean, they have more than 1,000 syscalls.
[07:46.360 --> 07:49.520]  It's a lot of things that are going to happen wrong.
[07:50.280 --> 07:55.960]  But recently they are going to refactor it, and we'll change the way we're talking later on.
[07:56.220 --> 07:59.060]  But the other thing, another part is ntusk kernel.
[07:59.060 --> 08:05.680]  It's also big, but on the other side, when you look at the CVs published by Microsoft,
[08:05.680 --> 08:11.580]  you cannot see too much, at least for memory corruption, too much memory corruption related to this part.
[08:11.660 --> 08:14.400]  And why? It's also really big.
[08:14.400 --> 08:16.380]  It's hundreds of syscalls.
[08:16.380 --> 08:26.760]  But the reason is that in this component, it's heavily used access-privileged checks and tokens,
[08:26.760 --> 08:35.700]  and it's restricted to not only what kind of syscall you can access, but what you can do.
[08:35.700 --> 08:42.540]  And it's checking, OK, you are not allowed to access this resource, so it just denies it.
[08:42.540 --> 08:52.540]  And the other thing is that logic that you can alter from via syscalls for these components,
[08:52.540 --> 08:57.800]  it's not so heavy for the work that they need to do, it's not so complicated.
[08:57.800 --> 09:02.860]  You can alter, for example, allocating memory, you free memory, you protect memory.
[09:02.860 --> 09:06.600]  Yeah, it's complex, but what you can alter, it's not so much.
[09:06.600 --> 09:12.320]  And also some lock or unlock mechanics, not so heavy logic you can play with.
[09:13.320 --> 09:15.600]  At least not for memory protection.
[09:15.600 --> 09:18.940]  You can find this, but it's hard, at least for int2k.
[09:19.940 --> 09:25.340]  But today it's not only about core components like MQS kernel or graphics subsystem,
[09:25.340 --> 09:33.560]  but there are a lot of different drivers, the windows kernel, but fortunately or unfortunately,
[09:33.560 --> 09:39.680]  it depends how you look at it, for our sandbox, usually you don't have access to it,
[09:39.680 --> 09:45.840]  at least most of the parts. But still, there are some interesting drivers which you can access.
[09:46.440 --> 09:51.680]  And when you're doing security research, you should be able to look further
[09:51.680 --> 09:55.380]  and to be more creative to find your different targets.
[09:55.380 --> 10:00.660]  Because when you find some links, some way how to attack some new attack surface,
[10:00.660 --> 10:04.160]  it's not like a jackpot for you, because it's probably not so well researched,
[10:04.160 --> 10:05.660]  it's not so well protected.
[10:07.980 --> 10:14.320]  So, taking interconnection with int2k, as I said, it's a really huge codebase and it's really old.
[10:14.780 --> 10:21.760]  So, at least for example, 4 years ago, when I started with exploitation, multi-networking,
[10:21.760 --> 10:27.540]  and hinting, I was really disappointed when I got my hands on int2k,
[10:27.540 --> 10:33.840]  because I got from my colleague a PDF bug, and OK, make exploitation.
[10:33.840 --> 10:38.940]  So I spent, I think, maybe one or two weeks just for understanding of how PDF works
[10:38.940 --> 10:42.380]  and basically analyzing the root cause of the bug.
[10:42.660 --> 10:48.460]  But then I get somehow, OK, I can inspect it once, so I can do some memory write or something.
[10:48.540 --> 10:53.400]  Then it takes me only, for example, two days to finish full exploit with code execution.
[10:53.400 --> 10:59.560]  And it was pretty much disappointing, because it was not my challenge.
[11:00.320 --> 11:04.680]  But it's changing, and it's very good.
[11:05.020 --> 11:10.440]  I mean, from my perspective, because I enjoy it more, and from security perspective, because it's becoming harder.
[11:11.140 --> 11:16.940]  And some changes that was introduced was that because, for example, 4 years ago, as I mentioned,
[11:16.940 --> 11:23.500]  I was working on TTF exploitation. But for now, TTF bugs, it's not so prominent now.
[11:23.500 --> 11:33.760]  Because they put it from the kernel mode, from custom foams to user modes, they get into some fairly restricted sandbox.
[11:33.820 --> 11:41.900]  So it means even if you can somehow find the vulnerabilities, for example, system foams,
[11:41.900 --> 11:47.360]  where you can't load your custom, if you can't load your custom foams, and you try to exploit,
[11:47.360 --> 11:52.120]  even if you exploit successfully, you end up in fairly restricted environments,
[11:52.120 --> 11:55.780]  most likely more restricted than you begin with.
[11:56.000 --> 11:58.240]  And that's the problem of 4 years exploiting.
[11:59.200 --> 12:02.760]  And also then, there is still Mint2K.
[12:03.300 --> 12:07.940]  For example, I mostly have Mint2K for several of my parts.
[12:07.980 --> 12:10.860]  A few of them are user parts and GTF parts.
[12:10.920 --> 12:17.460]  GTF part is responsible for driving a lot of some pretty nice things on screen.
[12:17.940 --> 12:21.020]  And the magic of this part is that you have a lot of objects.
[12:21.020 --> 12:27.520]  You have Bitmap, you have PC, you have Region, you have Palette, you have a lot of different objects.
[12:27.840 --> 12:31.780]  And the joy of this is that you can actually interact with each other.
[12:31.780 --> 12:33.980]  And the interaction is a problem.
[12:34.060 --> 12:42.740]  Because even if there will be no such complex code behind, it's still, when you say OK,
[12:42.740 --> 12:47.100]  for some object, OK, do this thing, but it incorporates this second object,
[12:47.100 --> 12:48.480]  it introduces a lot of problems.
[12:48.480 --> 12:51.360]  Because it needs, it has some connection.
[12:51.360 --> 12:53.820]  It can have some reference counting to each other.
[12:53.820 --> 12:57.340]  It can have some members dependent on the other members.
[12:57.340 --> 12:59.460]  And it can cause different problems.
[12:59.460 --> 13:02.780]  Like user-to-preset confusions, even overflows.
[13:03.120 --> 13:10.220]  But fortunately, Microsoft started to link this one some years ago.
[13:10.220 --> 13:13.060]  And they introduced, they started refactoring the code.
[13:13.060 --> 13:19.560]  And it's adding some filter sets, which basically tell you, OK, you cannot access these Ciscos,
[13:19.560 --> 13:21.860]  but you can access most of the Ciscos.
[13:21.860 --> 13:24.100]  Depends how you set your filter.
[13:24.580 --> 13:28.980]  But it's even better, you can even prohibit all of the big 2K Ciscos.
[13:28.980 --> 13:30.240]  That's pretty nice.
[13:30.240 --> 13:35.100]  But at the end, when the application is basically working, interactive user, you need it.
[13:35.100 --> 13:37.960]  So at some point your application, some process, will have access.
[13:37.960 --> 13:41.620]  But this filter set is meant for this one.
[13:41.620 --> 13:46.440]  And it's access only to the necessary functionality of this 3G 2K.
[13:48.180 --> 13:50.240]  And of course, there's the user part.
[13:50.240 --> 13:53.080]  And the user part is a huge thing.
[13:53.080 --> 13:57.700]  Actually, it was about 10 years ago, 15 years ago,
[13:57.700 --> 14:03.420]  there were some nice researches about using more callbacks.
[14:03.460 --> 14:07.340]  Basically, you decide, OK, I will call to Kernel.
[14:07.340 --> 14:11.060]  But Kernel will decide, OK, no, no, no, I need some more information.
[14:11.060 --> 14:14.880]  So what it will do, it will just stop and call back to user modes.
[14:14.940 --> 14:17.800]  But without exiting actual Cisco.
[14:17.800 --> 14:22.640]  And this is actually a big problem, because it's basically your state is pending,
[14:22.640 --> 14:32.720]  and you can involve some other threads to do something with the states of the country that this object is behind.
[14:34.060 --> 14:36.000]  It's hard to mitigate.
[14:36.000 --> 14:39.040]  But, as I said, with filter sets, it's harder to...
[14:40.140 --> 14:42.800]  It should be harder, to be true.
[14:42.800 --> 14:47.140]  But unfortunately, filter set allows all of this, user mode callbacks.
[14:47.340 --> 14:49.000]  And this is still a big issue.
[14:52.140 --> 14:56.440]  So, as I said, they're starting with filtering Cisco's.
[14:56.440 --> 14:57.920]  And it's the shortest request.
[14:57.920 --> 15:05.820]  I think this is the most efficient way how to protect some crucial parts of anything.
[15:06.480 --> 15:14.440]  And then, they don't stop here, but they go further for, OK, user vulnerability.
[15:14.480 --> 15:15.760]  That's the techniques.
[15:15.760 --> 15:18.440]  But now, can you somehow use this vulnerability?
[15:18.600 --> 15:22.660]  And that's, for example, this tag installation I will tell you about later.
[15:22.660 --> 15:27.780]  And as well, for target no mitigations, basically telling you, OK, you're using your vulnerability,
[15:27.780 --> 15:33.120]  you managed to somehow work with it, but can you actually use it for something meaningful?
[15:33.120 --> 15:37.220]  Like, read the rights to your targets, to get them.
[15:38.040 --> 15:41.300]  And also, the other thing is that excessive mitigations.
[15:42.220 --> 15:46.120]  Since Microsoft started to pay attention to this one,
[15:46.120 --> 15:53.160]  and they introduced a lot of programs like MS-DACI, Tobana, JIT, they need to decide their bounties.
[15:53.580 --> 15:59.360]  And all of this somehow encouraged researchers to publish, to report the more bugs.
[15:59.360 --> 16:01.020]  And you can see on the...
[16:01.460 --> 16:07.380]  For example, when I was fuzzing, when I was fuzzing the Mint 2.0 game,
[16:08.640 --> 16:13.500]  before, I found some bugs, some shallow bugs, but it can survive.
[16:13.500 --> 16:15.520]  One year, no problem.
[16:16.280 --> 16:22.280]  I don't make POC because I want to do more work, for example, on fuzzer itself.
[16:22.540 --> 16:25.440]  And I can come back to the bug, I think, one year later,
[16:25.440 --> 16:29.040]  and then I can make POC and make it useful, for example, on different competitions.
[16:29.040 --> 16:35.540]  But last year, I said, I still work on improving fuzzer,
[16:35.540 --> 16:41.420]  but then I see, OK, I have some bunch of bugs, but three months later, it was fixed.
[16:41.420 --> 16:47.020]  It was OK for some other bugs instead, but those bugs were fixed already.
[16:47.020 --> 16:48.340]  And it was really unexpected.
[16:48.480 --> 16:53.340]  So it seems that this is helping that security researchers are reporting bugs,
[16:53.340 --> 16:58.000]  and that they should probably do some internal fuzzing, which is really good for security.
[16:58.960 --> 17:03.900]  But on the other side, still, if it's OK, it's still alive.
[17:04.080 --> 17:12.200]  Why? It's because even when you have a more explicit filter set,
[17:12.200 --> 17:15.260]  still, you can access a lot of DirectX syscalls.
[17:15.620 --> 17:21.380]  And DirectX is pretty much a huge part,
[17:21.380 --> 17:27.180]  and still, it's, for example, the main component, which handles Microsoft itself.
[17:27.180 --> 17:32.420]  It's not so heavy logic, because it's only some allocations behind,
[17:32.420 --> 17:35.180]  but still, it's about four or five different objects,
[17:35.180 --> 17:37.540]  and you can interact, so you can find the bugs there.
[17:37.840 --> 17:42.640]  It's not promising as a user-oriented API, but still, good address interface.
[17:42.920 --> 17:45.420]  And in addition, when you're able to reach some bugs,
[17:45.420 --> 17:50.380]  which is not coded by Microsoft, but third-party vendors, like graphic vendors,
[17:50.380 --> 17:54.580]  they usually do some data parsing in Kernel, and this is probably the best.
[17:55.800 --> 18:00.680]  And as I mentioned, user-mode callbacks, still there, even with big filter sets,
[18:01.680 --> 18:06.320]  so this is also a problem, but probably they will somehow change it, maybe.
[18:06.320 --> 18:10.880]  Let's see. For now, it can be good source of bugs, and we'll care for it.
[18:12.100 --> 18:14.880]  And still, yes, it's still a smart part of GDR,
[18:14.880 --> 18:20.800]  but it's early, less and less, that you can attack, which is good.
[18:21.820 --> 18:24.560]  But still, even when you have applied, for example,
[18:24.580 --> 18:29.520]  all of these filter sets and lockdowns on IP2K,
[18:29.520 --> 18:32.780]  still it's possible that you can, as I said,
[18:32.780 --> 18:37.340]  your IPP can have more processes connected to each other,
[18:37.340 --> 18:41.280]  and some of them can have less restrictions on this IP2K.
[18:41.280 --> 18:46.060]  And so it's just a matter of getting it to get to those different processes,
[18:46.060 --> 18:50.920]  which you can use to call more systems. It's possible.
[18:52.080 --> 18:55.800]  So, coming to the next part, it's about the end-use kernel.
[18:56.240 --> 19:00.840]  This end-use kernel is also big, but it's harder to find a buyer for that.
[19:00.840 --> 19:06.200]  Why? The reason why is that, because this core component,
[19:06.200 --> 19:11.920]  as I heard from Max's guys, they put a lot of effort to review the code,
[19:11.920 --> 19:15.160]  it's a long time, and that's STL,
[19:15.160 --> 19:20.160]  and they take pretty much care that the things that you can use
[19:20.920 --> 19:25.960]  that you can access from low privilege level, it's well-reviewed.
[19:26.460 --> 19:31.160]  And that's for attacker, it's really bad, because, I mean,
[19:31.160 --> 19:34.680]  when you have logic like a lock, unlock, allocate,
[19:34.680 --> 19:38.080]  it's free of using the pipe or using the LPC,
[19:38.080 --> 19:41.140]  and it's really without defense.
[19:42.220 --> 19:45.260]  You can have a hard time to find that bug.
[19:45.420 --> 19:48.140]  And even, for example, LPC, LPC is quite big,
[19:48.140 --> 19:50.460]  and it's good features and documenting,
[19:50.460 --> 19:54.480]  so you can hope that you can find more bugs there.
[19:54.480 --> 19:57.080]  I think you can find bugs there, but, for example,
[19:57.080 --> 20:02.420]  when Windows exploits some bugs using LPC mechanism,
[20:02.420 --> 20:07.000]  I can see from the code that it's really written with some security perspective in mind.
[20:07.000 --> 20:09.940]  There's a lot of security checks that I didn't expect.
[20:10.160 --> 20:11.880]  And it's pretty nice to see.
[20:12.660 --> 20:17.200]  And also, when you look at NQS, sometimes you might lack luck,
[20:17.200 --> 20:19.800]  like we had before, one or two years ago,
[20:19.800 --> 20:22.760]  when we discovered some new attacker interface,
[20:22.760 --> 20:26.520]  well, new for community, because not too many people know about it, this one.
[20:26.680 --> 20:29.120]  And it was TN driver and CLT driver,
[20:29.420 --> 20:32.260]  which, for them, basically, you can access some goods
[20:32.740 --> 20:36.960]  that are passing by in kernel with low privileges.
[20:37.320 --> 20:39.640]  But that's almost gone for CLTs,
[20:39.640 --> 20:42.880]  because it's now locked down from low-privileged processes.
[20:44.940 --> 20:48.100]  And that's LPC. LPC is pretty cool.
[20:48.100 --> 20:50.940]  It also communicates between processes,
[20:50.940 --> 20:54.120]  or between different processes.
[20:54.420 --> 20:59.120]  And when you strip apart, OK, my target may not be necessarily the kernel,
[20:59.120 --> 21:02.840]  but it can be some other process, which has more privileges,
[21:02.840 --> 21:04.660]  and you're looking for it,
[21:04.660 --> 21:09.420]  so LPC can be a good way to go for it,
[21:09.640 --> 21:11.580]  because, against that concept,
[21:11.580 --> 21:14.220]  you may target not the kernel part, or the mechanism,
[21:14.220 --> 21:17.500]  but you may target the parts where the different processes
[21:18.900 --> 21:21.420]  basically process your packet you send to them.
[21:22.400 --> 21:25.480]  And good news, not news, but good things,
[21:25.480 --> 21:30.820]  is that, I think, every process has to open at least one LPC port.
[21:31.340 --> 21:33.740]  And with some part of luck,
[21:33.740 --> 21:35.960]  you may find that some of your processes
[21:35.960 --> 21:39.000]  that you can open, or you have already opened,
[21:39.000 --> 21:40.540]  if that thing works,
[21:40.540 --> 21:44.460]  and open a few different and promising attack circuits.
[21:44.940 --> 21:47.620]  But it's based on LPCs that are undocumented,
[21:47.620 --> 21:50.780]  so it means that you can have a hard time to understand it.
[21:50.860 --> 21:53.560]  But fortunately, there was some good research by Alex Yunescu,
[21:53.560 --> 21:56.440]  which brings more light to this area.
[21:56.660 --> 21:59.000]  And also, there were recent papers
[21:59.000 --> 22:04.140]  about the attacking of Vista,
[22:04.140 --> 22:05.400]  and it was pretty nice.
[22:06.960 --> 22:10.760]  But ok, let's assume we have known everything.
[22:11.360 --> 22:14.200]  But it's game over, it's easy to explain.
[22:14.560 --> 22:16.120]  Well, let's see.
[22:17.580 --> 22:20.360]  Before freeze, yes, it was quite straightforward,
[22:20.360 --> 22:23.460]  it was easy.
[22:23.480 --> 22:24.820]  But now we're changing it.
[22:24.820 --> 22:28.260]  I'm not saying that it's impossible, or it's really hard.
[22:28.280 --> 22:31.820]  But definitely it's a bit harder, at least.
[22:31.820 --> 22:35.020]  And sometimes it can be not possible,
[22:35.020 --> 22:36.740]  in some corner cases.
[22:37.660 --> 22:40.580]  For example, as I mentioned,
[22:40.580 --> 22:43.260]  you have the filter sets,
[22:43.260 --> 22:46.640]  that restrict you some part of the syscode that you can use.
[22:46.760 --> 22:49.040]  Then you have lockdowns, which was applied for graphics,
[22:49.040 --> 22:50.480]  and also for CLFS.
[22:50.960 --> 22:55.520]  Before freeze, we find that CLFS is very dangerous,
[22:55.520 --> 22:56.680]  from under the level.
[22:56.780 --> 22:58.920]  And this year we see that, ok, there are lockdowns,
[23:01.920 --> 23:03.300]  it's nice.
[23:04.060 --> 23:06.420]  And then you have, ok,
[23:06.420 --> 23:08.880]  that's the first thing,
[23:08.880 --> 23:11.140]  if you have a vulnerability,
[23:11.140 --> 23:14.740]  you think, can I use it?
[23:14.740 --> 23:17.820]  Can I really trigger that vulnerability and use it somehow?
[23:17.820 --> 23:20.280]  That's for its tactical mitigations,
[23:20.280 --> 23:24.340]  and some kind of time isolation and other things.
[23:24.420 --> 23:27.840]  But even after, ok, I achieved the rights,
[23:27.840 --> 23:29.980]  now I want to do some code execution,
[23:31.820 --> 23:32.740]  and data flow control.
[23:33.840 --> 23:36.800]  Data flow control is still, somehow,
[23:36.800 --> 23:38.880]  not so well mitigated.
[23:39.460 --> 23:41.700]  I mean, probably not at all.
[23:41.780 --> 23:44.160]  But about the code execution,
[23:44.160 --> 23:47.540]  it's starting to be more challenging.
[23:47.540 --> 23:52.060]  There are a lot of bugs, as you can see on the right side.
[23:52.500 --> 23:54.200]  It's a lot of bugs.
[23:54.360 --> 23:56.200]  So what are these bugs for?
[23:56.200 --> 24:00.100]  If you don't know about them, I recommend those two articles.
[24:01.820 --> 24:03.460]  Those are pretty much essential.
[24:03.500 --> 24:08.740]  They finally open the priorities,
[24:08.740 --> 24:10.920]  what are they doing,
[24:10.920 --> 24:12.460]  what they are doing,
[24:12.460 --> 24:14.620]  what are plans,
[24:15.740 --> 24:18.380]  what are the problems with my implementation,
[24:18.380 --> 24:19.720]  and some weaknesses.
[24:22.300 --> 24:25.400]  I mean, it's pretty much informative,
[24:25.400 --> 24:26.600]  those two articles.
[24:27.400 --> 24:29.780]  And especially for you when you want to apply
[24:34.900 --> 24:37.160]  some public APIs.
[24:38.540 --> 24:40.620]  So for process mitigation,
[24:40.620 --> 24:41.380]  it's CFG.
[24:41.380 --> 24:44.380]  Probably most of you guys already know about this one,
[24:44.380 --> 24:45.760]  so just pay attention.
[24:45.980 --> 24:50.360]  Basically, when you freight writes to your targets,
[24:50.360 --> 24:53.320]  one pretty much common technique was just,
[24:53.320 --> 24:55.200]  OK, I know that, for example,
[24:55.200 --> 24:58.280]  it's C++ code, and you still need toggles.
[24:58.280 --> 25:01.540]  So my target is, OK, I just find the input table,
[25:01.820 --> 25:03.840]  I change it, and next time,
[25:03.840 --> 25:06.300]  when there will be some object which I can invoke
[25:06.300 --> 25:08.440]  in the virtual world,
[25:08.440 --> 25:11.500]  basically it will just use this address
[25:11.500 --> 25:15.720]  and jump to where I want, and I get code execution for free.
[25:15.980 --> 25:17.560]  But with CFG,
[25:17.560 --> 25:21.580]  basically before this toggle appears,
[25:21.580 --> 25:23.400]  it's just checking if it's
[25:23.400 --> 25:27.660]  destination address is relatively correct,
[25:27.660 --> 25:28.960]  or not.
[25:31.820 --> 25:33.000]  It's just some approximation.
[25:33.080 --> 25:34.940]  But how can they do it?
[25:34.940 --> 25:39.840]  Actually, when you compile your process,
[25:39.840 --> 25:42.400]  your application, the CFG,
[25:42.400 --> 25:44.840]  it adds some information to its header,
[25:44.840 --> 25:47.980]  and at runtime, they can restore those information
[25:47.980 --> 25:49.440]  in an efficient way.
[25:50.200 --> 25:55.100]  To do a quick check, as quick as possible,
[25:55.100 --> 25:56.640]  and to do some approximation
[25:56.640 --> 26:00.820]  of what is valid and what is not valid,
[26:01.820 --> 26:03.740]  it's a little bit error-free.
[26:03.740 --> 26:06.540]  I mean, it's not so effective when you have, for example,
[26:06.540 --> 26:09.640]  you're working with a target which has
[26:09.640 --> 26:12.520]  JavaScript inside or some scripting engine,
[26:12.520 --> 26:15.080]  because simply you don't need to use this technique
[26:15.680 --> 26:17.860]  to generate some input table.
[26:18.100 --> 26:21.240]  But for some remote attacks, for example,
[26:21.240 --> 26:25.660]  if you want to attack through SMB or through Hyper-V,
[26:25.660 --> 26:27.200]  it can be a real issue.
[26:27.720 --> 26:31.800]  And that's the only thing for mitigations.
[26:31.820 --> 26:34.980]  To make it harder for execution.
[26:37.990 --> 26:38.490]  And so...
[26:39.170 --> 26:42.410]  But this is some fatal flaw,
[26:42.410 --> 26:45.670]  because you protect only from forward edges,
[26:45.670 --> 26:49.470]  only from when you want to invoke some call.
[26:49.510 --> 26:51.230]  And so it means backward edges,
[26:51.230 --> 26:54.630]  like changing the return address,
[26:54.630 --> 26:56.830]  it's still heavily unprotected.
[26:56.830 --> 26:59.530]  So what you will do,
[26:59.530 --> 27:01.850]  changing the input table, if you can just
[27:03.190 --> 27:05.290]  make it easy, at least in JavaScript,
[27:06.350 --> 27:09.310]  and just on this tag invite the return address.
[27:09.590 --> 27:12.770]  That is true, but I mean that for quite a reason,
[27:12.770 --> 27:15.110]  because there are a lot of terrible things.
[27:15.590 --> 27:17.430]  And Neo4j was pretty nice.
[27:17.510 --> 27:19.530]  I mean, it was a nice idea,
[27:19.530 --> 27:23.410]  because they introduced new memory,
[27:23.410 --> 27:26.450]  and what they're doing, when you do a call,
[27:26.450 --> 27:30.030]  they basically, at the beginning of the function,
[27:30.030 --> 27:32.150]  which is protected by this technology,
[27:33.190 --> 27:34.830]  this special region,
[27:34.830 --> 27:36.890]  the same return address.
[27:37.450 --> 27:40.370]  And at the return, they will check if the return address
[27:40.370 --> 27:42.950]  still matches with this one you've already saved.
[27:42.950 --> 27:44.770]  And if it doesn't match, it's failed.
[27:44.970 --> 27:49.350]  But if it matches, it means you should be safe.
[27:49.550 --> 27:54.910]  You should be safe, because it has some weaknesses.
[27:56.450 --> 27:58.710]  At first, I need to emphasize that
[27:58.710 --> 28:00.270]  I think it's a splendid idea,
[28:00.270 --> 28:02.590]  because it means that through this
[28:03.190 --> 28:05.350]  kind of methods, you can,
[28:05.350 --> 28:08.130]  for example, for Compound Logging Microsoft,
[28:08.130 --> 28:10.110]  I believe it can be hard to develop
[28:10.610 --> 28:12.450]  mitigation on large scale, because you need to
[28:12.450 --> 28:14.690]  deal with a lot of legacy stuff.
[28:15.130 --> 28:17.110]  And this way was very genius, I think,
[28:17.110 --> 28:20.830]  because you just compile, for example, your DLL
[28:20.830 --> 28:23.770]  with this technology, and you can just load it
[28:23.770 --> 28:27.830]  to unprotected process, and it will work.
[28:27.830 --> 28:30.890]  And you can load it to protected process, RNG,
[28:33.570 --> 28:35.770]  so it's pretty nice, doesn't break legacy,
[28:35.770 --> 28:38.990]  it's fast, only about 5 instructions, it's pretty neat.
[28:39.390 --> 28:42.510]  But the key weakness is that it's,
[28:42.510 --> 28:44.370]  as you can see on the previous slides,
[28:44.370 --> 28:46.850]  it has base conditions, I will show them in a moment.
[28:47.130 --> 28:49.770]  And the other thing is that it's backward-based.
[28:49.810 --> 28:53.070]  I mean, for this one, for example,
[28:53.070 --> 28:55.230]  for the shadow stack, it's in user mode,
[28:55.230 --> 28:56.990]  so it means you can write for this one.
[28:57.530 --> 29:01.570]  So, it's a problem. Now, what's the point
[29:03.190 --> 29:06.190]  that you can write, if you're already writing in Vue?
[29:06.190 --> 29:08.290]  You need to just find and rewrite it.
[29:08.350 --> 29:12.470]  But that's the key. The whole idea behind RNG
[29:12.470 --> 29:15.050]  was that we have no memory-pointed leaks
[29:15.050 --> 29:18.030]  to this region, and as you have terabytes
[29:18.030 --> 29:22.790]  of memory space, basically, if you hit the bed,
[29:22.790 --> 29:25.370]  then your process can be down and be killed.
[29:25.770 --> 29:28.390]  So, it's cool, it's just inefficient to search for it,
[29:28.390 --> 29:30.450]  because it's no memory leaks.
[29:30.450 --> 29:32.250]  But, what is the problem here?
[29:32.250 --> 29:35.650]  Because we have CPUs, which are not properly designed
[29:35.650 --> 29:38.710]  for security, and we have all those sidechannels.
[29:38.710 --> 29:42.110]  So, it means, second, this protection doesn't work.
[29:43.510 --> 29:46.370]  And, as I mentioned, first,
[29:46.370 --> 29:47.630]  those are base conditions.
[29:47.630 --> 29:50.190]  As you can see in the prologue and the epilogue,
[29:50.190 --> 29:53.030]  you can raise instructions, because,
[29:53.030 --> 29:56.730]  when you do call, the instruction will just
[29:57.650 --> 29:59.650]  redirect us to a normal stack.
[30:00.450 --> 30:03.930]  And the software can emulate it,
[30:03.930 --> 30:06.730]  so it will load it to your shadow stack.
[30:06.730 --> 30:09.410]  It basically cannot emulate, it just can wait
[30:09.410 --> 30:11.950]  until it's called, then it can read from the stack
[30:11.950 --> 30:13.890]  when it was original stored, and then put it
[30:13.890 --> 30:15.430]  on the shadow stack.
[30:15.910 --> 30:19.270]  And this is a bit of a risk condition.
[30:21.490 --> 30:23.890]  I believe that's... I think that's...
[30:23.890 --> 30:26.030]  There was people thinking that's OK,
[30:26.030 --> 30:27.770]  of course they know about this risk condition,
[30:30.450 --> 30:32.410]  but it's been in some reasonable manner.
[30:32.650 --> 30:35.590]  But in fact, as this happened, some submission,
[30:35.590 --> 30:38.890]  successfully, it was able, and was able to
[30:39.270 --> 30:40.430]  safely to do it.
[30:42.990 --> 30:46.710]  But, if allergies do some,
[30:46.710 --> 30:47.890]  at least, for example, it's for this
[30:47.890 --> 30:50.050]  to be consistent, it's cooled down,
[30:50.050 --> 30:52.210]  so it's, again, it's not protected by allergies,
[30:52.210 --> 30:55.110]  but no worries, it will go to your back,
[30:55.110 --> 30:57.290]  and maybe in three years, five, I don't know
[31:00.450 --> 31:03.050]  and that will mean that it will be protected
[31:03.050 --> 31:06.990]  calls and returns by half itself,
[31:06.990 --> 31:08.910]  which is always pretty neat.
[31:08.910 --> 31:11.790]  It will be not probably 100% secure
[31:12.130 --> 31:14.930]  for attacks against hijacking
[31:15.210 --> 31:17.390]  counterflow, but it's built pretty much
[31:17.390 --> 31:22.350]  by boundary for you to bypass.
[31:24.010 --> 31:26.630]  And, but, let's say that OK,
[31:26.630 --> 31:30.070]  forward and backward edges is still important,
[31:30.070 --> 31:32.250]  but it seems they don't stop there.
[31:32.250 --> 31:36.390]  Why? Simply because before, and also nowadays,
[31:36.390 --> 31:39.530]  when you have, for example, CFG and whites,
[31:39.530 --> 31:41.290]  and you start with error ping.
[31:41.290 --> 31:43.770]  Error ping is pretty nice, but it can
[31:43.770 --> 31:47.050]  be problematic when you need to do all payloads,
[31:47.050 --> 31:49.210]  just by error ping, call all the syscalls,
[31:49.210 --> 31:52.830]  all the arguments, and that's why
[31:52.830 --> 31:56.530]  the people usually just allocate
[31:56.530 --> 31:59.550]  new memory, put their codes,
[32:00.070 --> 32:01.250]  into the executable, and then just
[32:01.250 --> 32:04.690]  jump this one, for example,
[32:04.690 --> 32:08.230]  through changing the return address.
[32:08.830 --> 32:11.370]  And that's where CAG, ACG,
[32:11.370 --> 32:13.250]  and the other codes come to play.
[32:15.030 --> 32:17.890]  To prevent this kind of execution,
[32:17.890 --> 32:19.990]  your own codes inside your targets.
[32:20.050 --> 32:22.690]  So first, CAG, Code Integrated Guards,
[32:22.690 --> 32:24.950]  is linked to be, OK, it will be a trivial,
[32:24.950 --> 32:26.850]  then you can just, through error ping,
[32:30.070 --> 32:32.050]  and that's it, because the library can be
[32:32.050 --> 32:34.630]  wrong if you before drop the file,
[32:34.630 --> 32:37.250]  and basically, you won already.
[32:37.710 --> 32:40.330]  But CAG says, OK, no, no, you cannot do it,
[32:40.330 --> 32:42.930]  because it's not a valid signature,
[32:42.930 --> 32:45.210]  and as an attacker, it probably shouldn't
[32:45.210 --> 32:48.730]  be easy for you to get a valid signature.
[32:50.670 --> 32:53.190]  But still, OK, we can unload the library,
[32:53.190 --> 32:55.430]  but OK, we can go for allocating memory
[32:55.430 --> 32:58.790]  and making an executable, so OK,
[33:00.250 --> 33:03.270]  Arbitrary Code Guards say, OK, no, you cannot do it,
[33:03.270 --> 33:05.750]  because once memory is breakable,
[33:05.750 --> 33:07.750]  you can't change it to executable anymore.
[33:08.090 --> 33:10.950]  And then, wow, but this is interesting.
[33:11.290 --> 33:14.230]  Then when it comes to browsers, like Niche,
[33:14.230 --> 33:17.070]  they have JIT, JIT Engine,
[33:17.070 --> 33:19.010]  and what they really need is,
[33:19.010 --> 33:23.470]  but OK, and this is also a pretty nice design,
[33:23.470 --> 33:24.910]  so how do they deal with this one?
[33:24.910 --> 33:26.870]  So they just say, OK, we don't need it,
[33:30.070 --> 33:31.810]  because in your own process,
[33:31.810 --> 33:35.290]  you cannot disable Arbitrary Code Guards,
[33:35.290 --> 33:37.950]  but what you can do, is that different processes
[33:37.950 --> 33:39.250]  can do it for you.
[33:39.570 --> 33:43.290]  So they basically introduce another process,
[33:43.290 --> 33:45.470]  which basically unpacks an idiom,
[33:45.470 --> 33:48.890]  injects the code inside your target process,
[33:48.890 --> 33:51.510]  and makes it executable.
[33:51.910 --> 33:54.630]  And of course, there are CRG and these kind of things for it.
[33:55.170 --> 33:58.190]  So it's also a neat design, but on the other side,
[34:00.390 --> 34:01.450]  there's a problem, because there's a problem,
[34:01.450 --> 34:05.230]  OK, what about framing the memory in my own process,
[34:05.230 --> 34:07.870]  when the different processes allocate bits,
[34:07.870 --> 34:10.390]  and getting or rewrite the memory?
[34:10.890 --> 34:13.530]  There are lots of tricky things to do,
[34:13.530 --> 34:17.210]  but I guess they will handle it step by step.
[34:18.030 --> 34:20.250]  So it's very nice to see that Microsoft
[34:20.250 --> 34:23.330]  is doing this kind of challenging thing for us.
[34:24.530 --> 34:26.270]  And another thing, OK, this is not
[34:26.270 --> 34:27.810]  the native code execution piece,
[34:31.870 --> 34:34.890]  but before you can get native code execution,
[34:34.890 --> 34:39.410]  or data boning, and just rewriting some data,
[34:39.410 --> 34:41.070]  I think it's pretty much equal, by the way,
[34:41.070 --> 34:44.290]  to data tricks and code selection attacks.
[34:44.350 --> 34:46.150]  It just depends on the viewer.
[34:46.370 --> 34:48.590]  But even before you can do this one,
[34:48.590 --> 34:51.430]  you need to get good control of your room already.
[34:52.010 --> 34:54.910]  And that one was the next point,
[34:54.910 --> 34:57.690]  how to mitigate those kind of things.
[34:57.930 --> 34:59.730]  And one of these interesting things was
[35:00.070 --> 35:02.070]  how isolation algorithms were used.
[35:02.870 --> 35:06.150]  And, for example, before we have some technique
[35:06.150 --> 35:11.370]  that we have some object in Kata,
[35:11.370 --> 35:12.830]  which have some header and other,
[35:12.830 --> 35:14.610]  and they are really putting together.
[35:14.730 --> 35:17.850]  But the problem with this one is this,
[35:17.850 --> 35:20.670]  that when you can from those data overflow,
[35:20.670 --> 35:23.870]  when you have some bug in handling your object,
[35:23.870 --> 35:26.070]  and you can overflow to different objects,
[35:26.730 --> 35:29.070]  and then you can alter this data,
[35:30.070 --> 35:34.410]  so that's when comes type selection in.
[35:34.410 --> 35:37.850]  This separates different objects,
[35:37.850 --> 35:40.650]  headers and data, different chunks.
[35:41.050 --> 35:43.890]  Not all of them, but I guess pretty much this one.
[35:44.230 --> 35:45.950]  Even if you have overflow,
[35:45.950 --> 35:49.890]  it will be hard for you to attack the critical structures.
[35:50.150 --> 35:52.450]  And even if you have some result-free,
[35:52.450 --> 35:55.930]  it will be very difficult to,
[35:55.930 --> 35:57.830]  or maybe impossible,
[35:57.830 --> 36:02.110]  it will be difficult to get the different objects
[36:02.110 --> 36:04.250]  that were originally supposed to be there.
[36:04.910 --> 36:06.530]  That's a bit nice.
[36:07.070 --> 36:09.710]  But, for example, when it comes to overflows,
[36:09.710 --> 36:16.450]  if you have some crucial thing,
[36:16.450 --> 36:17.670]  that it will tell, for example,
[36:18.170 --> 36:20.610]  about the tactical mitigations.
[36:22.990 --> 36:23.470]  Because...
[36:23.470 --> 36:27.370]  I mean, about tactical mitigations,
[36:27.830 --> 36:29.490]  there is another thing that's OK,
[36:29.490 --> 36:31.170]  that you can get another control
[36:32.570 --> 36:34.090]  of your vulnerability,
[36:34.090 --> 36:36.730]  that you can somehow put it in a good object
[36:36.730 --> 36:41.010]  or it would get a lot of different objects.
[36:41.150 --> 36:43.370]  And now we can start working with it.
[36:43.390 --> 36:45.510]  And it was some known techniques,
[36:45.510 --> 36:50.530]  like BND or BigMap attacks.
[36:50.790 --> 36:51.990]  And if I get attacks,
[36:51.990 --> 36:53.850]  and they use the same pattern,
[36:57.870 --> 36:59.350]  that's our pointer.
[37:00.610 --> 37:02.890]  And that's why I was focusing on...
[37:04.750 --> 37:06.490]  it's not some generic approach,
[37:06.490 --> 37:08.430]  it's approach one by one.
[37:08.750 --> 37:10.450]  But it kind of helps, because when you know
[37:10.450 --> 37:12.110]  that a lot of people are using this technique
[37:12.110 --> 37:14.250]  and blocks it, eventually maybe
[37:14.250 --> 37:17.070]  it will get out of the arsenal.
[37:17.790 --> 37:22.250]  But what's going on here is that basically
[37:22.250 --> 37:26.830]  when before you do some manipulation over,
[37:27.830 --> 37:28.730]  for example, a pointer,
[37:28.730 --> 37:31.930]  index or some buffer, they will check it at first.
[37:31.930 --> 37:35.010]  OK, is this buffer, is this index inside
[37:36.210 --> 37:37.690]  some outer edges?
[37:37.690 --> 37:40.250]  If it's a buffer, it's quite cool.
[37:40.950 --> 37:43.590]  And that's what's called tactical mitigation.
[37:43.610 --> 37:46.710]  And it somehow helps to at least bank some techniques,
[37:46.710 --> 37:48.810]  or at least to make them harder.
[37:48.850 --> 37:51.350]  But what's crucial for this mitigation is that
[37:52.590 --> 37:55.390]  you should not be able to...
[37:57.990 --> 38:00.310]  you can have some limited safe writes
[38:00.660 --> 38:03.230]  in some boundaries, but being inside those boundaries
[38:03.230 --> 38:05.950]  has an important structure, which basically
[38:05.950 --> 38:08.830]  checks after those boundaries,
[38:09.710 --> 38:12.330]  and if it affects that one, it won't.
[38:12.330 --> 38:14.270]  And that was happened...
[38:14.270 --> 38:17.870]  at that article, I referenced it a lot,
[38:17.870 --> 38:19.990]  it's by Mortensen, and you can read it,
[38:19.990 --> 38:22.150]  it was, I think, a pretty nice bypass
[38:24.610 --> 38:27.810]  of one particular tactical mitigation.
[38:28.450 --> 38:30.050]  Targeting the BND.
[38:31.830 --> 38:33.510]  So, how it looks like.
[38:33.750 --> 38:36.730]  For example, on one of our bugs,
[38:36.730 --> 38:38.950]  I was checking, OK, it can be used,
[38:38.950 --> 38:42.190]  because it looks like a write, only primitive.
[38:42.190 --> 38:45.770]  So I try to check if it can be used also as a write primitive.
[38:45.790 --> 38:49.230]  So I'm going through the code, some different branches,
[38:49.230 --> 38:51.850]  and then in one branch, I see this kind of check.
[38:51.850 --> 38:53.910]  At the beginning, you see,
[38:54.510 --> 38:56.530]  B19 is less than B20,
[38:56.530 --> 38:58.470]  and B4 is bigger than B13,
[38:58.470 --> 39:01.430]  it just doesn't cross it more.
[39:01.550 --> 39:03.730]  And this kind of checks are usually
[39:04.470 --> 39:06.630]  not in place when you code, because
[39:06.630 --> 39:09.290]  as a developer, you will write some code,
[39:09.290 --> 39:11.530]  and you build, for example, some objects,
[39:11.530 --> 39:14.010]  and you will use index to index the memory,
[39:14.010 --> 39:18.250]  because this should be correct, this should be valid.
[39:18.510 --> 39:20.910]  But when an attacker can change it,
[39:23.990 --> 39:26.210]  and that's why you have this kind of checks,
[39:26.210 --> 39:28.530]  but as a normal developer, when developing code,
[39:28.530 --> 39:29.830]  you will not think of this one.
[39:29.830 --> 39:33.410]  But when you do some mitigations, like static ones,
[39:33.410 --> 39:36.170]  you will check for this education.
[39:37.250 --> 39:39.930]  Because if it's not this check,
[39:39.930 --> 39:42.430]  we can use it to write anywhere in the kernel,
[39:42.430 --> 39:46.330]  but this checks if it's a good full boundary,
[39:46.330 --> 39:47.830]  and goes a bit troublesome.
[39:49.490 --> 39:52.630]  So in fact, in theory,
[39:53.910 --> 39:57.050]  because Windows is developing these mitigations
[39:58.330 --> 39:59.510]  pretty much fast,
[39:59.510 --> 40:00.890]  I would say you have, I don't know,
[40:00.890 --> 40:05.070]  maybe 80 or more native code execs mitigations,
[40:05.070 --> 40:08.430]  and you have this type of static mitigations,
[40:08.430 --> 40:10.790]  type of isolations, and different kind of things,
[40:10.790 --> 40:12.050]  which is pretty nice.
[40:12.050 --> 40:14.770]  So in theory, it should be pretty nice strongholds,
[40:14.770 --> 40:20.030]  so you cannot do any more to re-write the memory,
[40:20.030 --> 40:22.050]  you cannot load arbitrary modules,
[40:24.730 --> 40:25.630]  RIPs,
[40:25.630 --> 40:28.030]  and also even overflows,
[40:28.030 --> 40:31.710]  there will be some limits that you cannot touch anywhere in the kernel,
[40:31.710 --> 40:33.510]  but just in some parts.
[40:33.510 --> 40:35.910]  But it's some kind of suggestions in theory.
[40:36.490 --> 40:39.390]  It certainly makes it a little bit harder,
[40:39.390 --> 40:41.170]  but it's not game over,
[40:41.170 --> 40:44.390]  because it's still a lot of legacy,
[40:44.390 --> 40:48.970]  so it's hard to do it in large scale properly,
[40:48.970 --> 40:52.910]  and also there's a lot of,
[40:55.550 --> 40:57.630]  then you have some...
[40:57.630 --> 40:59.650]  Recently, for example, in mitigation,
[40:59.650 --> 41:03.390]  when you can see mitigation rules,
[41:03.390 --> 41:04.890]  mitigation mappable rules,
[41:04.890 --> 41:07.850]  you can see that it's out of scope for some categories,
[41:07.850 --> 41:10.170]  race conditions, and it's a butterfuck.
[41:10.170 --> 41:12.970]  Race conditions, I mean, when you write race conditions,
[41:12.970 --> 41:16.290]  it's like saying, OK, we have a really big problem,
[41:16.290 --> 41:18.250]  because we cannot defend against them,
[41:18.250 --> 41:22.910]  but it's still a big problem, because you have process,
[41:23.910 --> 41:24.950]  you have a lot of environments.
[41:26.190 --> 41:28.830]  But it looks like it's really hard to protect
[41:29.670 --> 41:32.110]  against some race conditions.
[41:34.430 --> 41:36.410]  But at least, I want to say that
[41:36.410 --> 41:40.630]  in Windows, what I like from past years, from now,
[41:40.630 --> 41:41.990]  that's the way changing,
[41:42.810 --> 41:45.910]  looking at the early shift towards security,
[41:46.550 --> 41:48.470]  and that at least makes for me,
[41:48.470 --> 41:51.990]  it's a bit more challenging, I can more use my brain,
[41:51.990 --> 41:55.410]  it's not like, OK, I just sit one or two days,
[41:55.410 --> 41:57.710]  and it's done. But now I need to, OK,
[41:57.710 --> 42:00.530]  be more creative. So for me, it's good.
[42:00.770 --> 42:02.710]  And also for normal users, it's good,
[42:02.710 --> 42:06.310]  because it makes for all the people
[42:06.310 --> 42:07.690]  to work harder.
[42:09.330 --> 42:13.730]  So, we have sandbox, we have native code executions,
[42:13.730 --> 42:15.910]  we have some tactical mitigations,
[42:15.910 --> 42:19.050]  but what else? Still, a lot of bugs,
[42:19.050 --> 42:21.650]  and still people bypass it,
[42:21.990 --> 42:23.610]  and introduce some new thing,
[42:23.610 --> 42:26.290]  I mean, it's not new thing, but it's coming to life,
[42:26.290 --> 42:28.250]  that you see,
[42:29.270 --> 42:31.390]  make use of virtualization.
[42:31.710 --> 42:34.230]  And virtualization is pretty neat, because as I said before,
[42:34.230 --> 42:37.070]  I enjoy Kernel, because I like it,
[42:37.070 --> 42:41.190]  but also because, before, you own Kernel,
[42:41.190 --> 42:43.550]  you own, but now you own Kernel,
[42:43.550 --> 42:48.230]  and it can be just one point in your checkbox,
[42:48.230 --> 42:49.390]  in your to-do list.
[42:52.730 --> 42:55.850]  And it's limited,
[42:55.850 --> 42:57.210]  you can link the data,
[42:58.690 --> 43:00.770]  and that's not all what you want,
[43:00.770 --> 43:02.050]  you want less data.
[43:02.630 --> 43:07.250]  And that's what virtualization is about.
[43:07.450 --> 43:10.030]  And really good is that they are using Hyper-V,
[43:10.030 --> 43:13.950]  because Hyper-V is well designed,
[43:13.950 --> 43:15.090]  when you look inside,
[43:15.830 --> 43:18.750]  you see that also a lot of security perspective
[43:18.750 --> 43:21.970]  applied to this module.
[43:21.990 --> 43:24.790]  And you can see that it's a lot of C++,
[43:24.790 --> 43:27.630]  I mean, I enjoy C++, but on the side,
[43:27.630 --> 43:30.770]  it can be bad because C++ is really hard to do it good,
[43:30.770 --> 43:34.550]  it's really easy to make mistakes, and bad mistakes.
[43:34.650 --> 43:38.510]  But when you look at these components,
[43:38.510 --> 43:39.810]  it's not C++ is good,
[43:39.810 --> 43:43.950]  it's code, it's pointers, they are pretty much separation of logic,
[43:43.950 --> 43:45.810]  it's clean design.
[43:46.290 --> 43:47.990]  So it's... I like it.
[43:47.990 --> 43:51.430]  I mean, it's challenging, when you want to find bugs there,
[43:51.990 --> 43:53.450]  it's a big challenge,
[43:53.450 --> 43:57.090]  and when you go on the kernel,
[43:57.090 --> 44:00.410]  and these are the applied, you may have problems.
[44:02.510 --> 44:04.290]  So, for example,
[44:04.290 --> 44:07.750]  about Hyper-V, one of the core components is VNVP.
[44:07.750 --> 44:08.770]  And what's VNVP?
[44:09.630 --> 44:11.630]  It's a virtual machine order process.
[44:11.630 --> 44:14.170]  It's basically the process in the host,
[44:14.170 --> 44:16.470]  which manages the virtual machine.
[44:17.490 --> 44:18.870]  Now this you can maybe,
[44:18.870 --> 44:23.410]  when you try to hyper-application guards,
[44:23.410 --> 44:25.530]  so you can try it.
[44:25.530 --> 44:27.570]  But you can see that it's not so useful,
[44:27.570 --> 44:30.630]  because you can maybe go to Twitter or watch porn sites,
[44:30.630 --> 44:34.070]  but it's not so useful for real applications,
[44:34.070 --> 44:37.790]  for real life, because all those data are just inside the container.
[44:38.150 --> 44:40.910]  But in the future, it will be a bit more and more applicable.
[44:42.730 --> 44:43.170]  And...
[44:45.070 --> 44:47.410]  this VNVP will be more crucial.
[44:47.970 --> 44:49.230]  And when you look
[44:50.430 --> 44:53.090]  on the virtual machine that's going inside,
[44:53.090 --> 44:54.790]  for example, about the emulates,
[44:54.790 --> 44:57.210]  you will see that it's not a lot of things,
[44:57.210 --> 45:00.170]  it's relatively clean,
[45:01.210 --> 45:03.170]  and you have minimal...
[45:03.770 --> 45:05.530]  you don't have too much legacy,
[45:05.530 --> 45:07.530]  you don't have a drag-and-drop,
[45:07.530 --> 45:09.430]  you have basic sessions by default,
[45:13.170 --> 45:13.850]  so it's...
[45:15.730 --> 45:17.270]  it's not a big attack surface,
[45:17.270 --> 45:20.190]  as some other virtual machines maybe.
[45:20.790 --> 45:23.710]  And it can be good, but as I use it,
[45:23.710 --> 45:25.670]  as I try to use it sometimes,
[45:25.670 --> 45:27.450]  as for example for browsing,
[45:27.450 --> 45:29.850]  I don't feel it too much,
[45:29.850 --> 45:35.650]  so I don't think it's a virtualization as boundaries right now here,
[45:35.650 --> 45:38.030]  but I think maybe soon will be.
[45:38.030 --> 45:40.470]  So for this one, the reference
[45:41.030 --> 45:44.410]  type of VNVP can be pretty good.
[45:45.590 --> 45:47.230]  So in the future,
[45:47.230 --> 45:49.430]  what it looks like, maybe the attack,
[45:49.430 --> 45:54.290]  it can be composed from many small parts,
[45:54.290 --> 45:55.810]  because you need, at first,
[45:55.810 --> 45:58.810]  to get back in your target, which can be browser,
[45:58.810 --> 46:03.250]  it can be some ADP, like Skype or whatever,
[46:03.250 --> 46:05.170]  and then it's OK, you get back.
[46:05.170 --> 46:07.750]  Then you need to get the remote code execution,
[46:07.750 --> 46:10.350]  so you need to bypass some net code execution bugs,
[46:10.350 --> 46:14.150]  and before, maybe you need to handle the tag isolation,
[46:14.150 --> 46:15.110]  this kind of things.
[46:15.290 --> 46:17.770]  Then, OK, I get the remote code execution,
[46:17.770 --> 46:20.870]  but I need to escape from the sandbox. And why?
[46:22.190 --> 46:24.550]  Because I'm inside the virtualization,
[46:24.550 --> 46:26.650]  so I need to attack the cadena, the improviser.
[46:26.650 --> 46:28.890]  But the improviser can attack only from the cadena,
[46:28.890 --> 46:31.830]  so even, for example, I got out from the sandbox,
[46:35.170 --> 46:38.230]  then it's true, be sure to look for the cadena,
[46:38.650 --> 46:41.330]  or at least, I have no need, maybe,
[46:41.330 --> 46:43.790]  in code execution there, but at least it writes.
[46:44.290 --> 46:47.670]  And from that point, you need to find the bug in virtualization,
[46:47.670 --> 46:49.310]  and then you have the bug in virtualization,
[46:49.310 --> 46:52.010]  and to be able to exploit it, and when you have exploited it,
[46:52.010 --> 46:55.190]  so in that host, when you are in cadena, it's OK,
[46:55.190 --> 46:57.830]  but when you are in user mode, then you still need to find
[46:57.830 --> 47:01.230]  where it was also in virtualization, it's locked down.
[47:01.790 --> 47:04.890]  So it can be... it's promising,
[47:05.170 --> 47:06.710]  it can be a good challenge in the future.
[47:07.350 --> 47:11.050]  They are not there, but I believe that they will be,
[47:11.050 --> 47:13.390]  at one point, and it will be interesting.
[47:13.910 --> 47:17.050]  At least, for me, it will be a nice challenge.
[47:19.210 --> 47:22.790]  So, but still, before all of this,
[47:22.790 --> 47:26.150]  when you want to exploit, make use of sandbox,
[47:26.150 --> 47:27.690]  you need first to find them.
[47:28.110 --> 47:29.330]  So how to do it?
[47:30.510 --> 47:33.090]  Actually, before, it was more troublesome,
[47:33.090 --> 47:34.910]  because you don't have too much open source tools,
[47:34.910 --> 47:37.290]  you need to create your own clusters,
[47:37.290 --> 47:40.550]  and by creating the things, I mean,
[47:40.550 --> 47:42.890]  it's nice to create it and everything,
[47:42.890 --> 47:46.870]  but it can be a little over-engineered.
[47:47.350 --> 47:49.710]  And at first, for example now,
[47:49.710 --> 47:51.990]  you have pretty much a lot of open source tools,
[47:51.990 --> 47:53.650]  you have syscaller, you have key,
[47:53.650 --> 47:57.690]  you have hypervisors, which you can utilize,
[47:57.690 --> 48:00.330]  which you have also, you have qm, kvm,
[48:03.090 --> 48:05.310]  which is not just for debugging,
[48:05.310 --> 48:08.150]  and you have the technologies for debugging.
[48:08.150 --> 48:10.730]  You can use all of these,
[48:11.890 --> 48:14.270]  and it will help you, and you have all the resources.
[48:14.270 --> 48:16.410]  But I don't recommend to start, for example,
[48:16.410 --> 48:19.470]  to make it faster from the scratch.
[48:19.610 --> 48:21.450]  At first, I guess you need to understand
[48:21.450 --> 48:25.830]  how the state-of-the-art tools work.
[48:26.190 --> 48:28.830]  Those are, for example, KFL,
[48:28.830 --> 48:32.650]  and when you want to work in the kernel,
[48:33.090 --> 48:35.810]  you can use an adaptation in the form of KFL,
[48:35.810 --> 48:38.930]  which you can also use for Windows or for other platforms,
[48:38.930 --> 48:40.670]  and the same applies for syscaller.
[48:40.670 --> 48:45.330]  KFL is for data-fuzzing, and syscaller is for state-fuzzing.
[48:46.090 --> 48:47.730]  And so at first,
[48:47.730 --> 48:50.570]  when you understand the square root of tools,
[48:50.570 --> 48:53.150]  and you know how to work with them,
[48:54.450 --> 48:56.090]  what their weaknesses are,
[48:56.090 --> 48:57.590]  and what you want to improve,
[48:57.590 --> 49:00.210]  then I suppose you should go further
[49:03.090 --> 49:04.450]  with your own tool.
[49:04.830 --> 49:07.190]  Depends. Depends case by case.
[49:07.190 --> 49:11.170]  But at first, I think it's not a good idea
[49:11.170 --> 49:14.110]  to rely on this wheel again and again.
[49:14.110 --> 49:16.050]  At first, understand, and then see
[49:16.050 --> 49:19.650]  if you really need to do something new,
[49:19.650 --> 49:21.810]  and if yes, then do it good.
[49:23.570 --> 49:26.250]  And then the really common question,
[49:26.870 --> 49:29.510]  maybe not a question, but it's there to approaches.
[49:29.530 --> 49:32.950]  People are a lot of times just looking for bugs.
[49:36.750 --> 49:39.510]  But what I would like to do
[49:39.510 --> 49:41.290]  is combine those two approaches.
[49:41.450 --> 49:43.550]  Why? Because who's fuzzing?
[49:43.750 --> 49:46.190]  It's fuzzing super easy.
[49:46.190 --> 49:47.810]  I mean, you can write a program,
[49:47.810 --> 49:49.150]  and you can call it fuzzer.
[49:49.410 --> 49:51.950]  And it's okay, because it does something,
[49:51.950 --> 49:54.270]  but it depends if it does something reasonable.
[49:54.270 --> 49:56.610]  Because it's really easy to do just fuzzer,
[49:56.610 --> 49:57.990]  which does nothing.
[50:03.090 --> 50:04.770]  If you tell him exactly what to do,
[50:04.770 --> 50:06.270]  or limit him too much,
[50:06.270 --> 50:08.890]  it will not be random enough,
[50:08.890 --> 50:12.010]  or will not do enough house and interesting behavior.
[50:12.150 --> 50:14.630]  Because people just look at some
[50:15.430 --> 50:17.350]  some predefinite paths.
[50:18.170 --> 50:22.090]  On the other side, when you're looking just by eyes,
[50:22.090 --> 50:24.270]  well, it can be really tiring for you.
[50:25.650 --> 50:27.070]  You can find...
[50:27.070 --> 50:30.590]  you can easily sleep some easy bug
[50:33.270 --> 50:35.270]  or, on that side,
[50:35.890 --> 50:39.330]  it's really hard to comprehend some complex connections.
[50:39.370 --> 50:42.390]  For example, some race conditions,
[50:42.390 --> 50:45.410]  or some connection five lives ago,
[50:45.410 --> 50:47.670]  some connections, two things together.
[50:48.170 --> 50:52.230]  And this can be really hard to comprehend,
[50:52.230 --> 50:54.610]  really, to see the bug there.
[50:54.970 --> 50:56.850]  And also, the same applies for the fuzzer.
[50:56.850 --> 51:01.450]  It's not so easy for the fuzzer to go for some deep bugs,
[51:01.450 --> 51:03.070]  but on that side,
[51:03.090 --> 51:05.190]  when you combine these two approaches together,
[51:05.190 --> 51:07.310]  it can have a good effect.
[51:07.510 --> 51:11.330]  You will just see a lot of random fuzzer,
[51:11.330 --> 51:12.630]  and then you will improve.
[51:12.630 --> 51:16.210]  OK, I get a deep bug, for example, I cover these parts,
[51:16.210 --> 51:18.670]  but I know that this part seems more interesting,
[51:18.670 --> 51:19.950]  so I want to go more deep.
[51:19.950 --> 51:23.150]  So I will shift the fuzzer, for example, templates,
[51:23.150 --> 51:26.870]  and some logic in the fuzzer, to go with that part finally.
[51:27.310 --> 51:30.370]  And maybe to provide some callbacks,
[51:33.090 --> 51:34.850]  and enhance the fuzzing.
[51:35.590 --> 51:37.670]  It's a lot of things, what you can do.
[51:40.530 --> 51:42.090]  And also, the other thing,
[51:43.530 --> 51:45.670]  is choosing about the targets.
[51:46.890 --> 51:49.570]  As you see, I'm not just about the browsers.
[51:49.570 --> 51:52.710]  Browsers are just one thing,
[51:52.710 --> 51:56.130]  which is really dangerous, if it's done wrong.
[51:56.270 --> 51:57.850]  But there are a lot of applications,
[51:57.850 --> 52:00.610]  which basically communicate with the Internet.
[52:00.610 --> 52:02.150]  So when you are using Skype,
[52:02.150 --> 52:04.090]  when you are using Slack,
[52:04.830 --> 52:07.330]  emails, or different applications,
[52:07.330 --> 52:09.690]  a lot of things communicate with the Internet.
[52:10.250 --> 52:12.070]  And so when you know that your target
[52:12.070 --> 52:14.890]  is using this program,
[52:14.890 --> 52:17.490]  and you know, for example, this is weaker than some browser,
[52:17.490 --> 52:20.170]  then you probably go for that one. Why not?
[52:21.690 --> 52:23.330]  And this is also SMB.
[52:25.350 --> 52:27.110]  Because there were some bugs,
[52:31.510 --> 52:32.630]  not so easy bugs,
[52:32.630 --> 52:35.430]  but for me it's unbelievable that those kinds of bugs exist.
[52:35.430 --> 52:37.150]  Non-authenticated bugs.
[52:39.310 --> 52:41.470]  But when you run some simple dummy fuzzing,
[52:41.470 --> 52:43.910]  you can find a lot of those bugs.
[52:44.310 --> 52:47.970]  I mean, not dummy fuzzing,
[52:47.970 --> 52:51.010]  but for example, more efficient, like APM,
[52:51.010 --> 52:53.190]  that has some strategy approach to find them.
[52:53.290 --> 52:55.630]  But when you just apply, I think, baseline,
[52:55.630 --> 52:56.830]  you will find them.
[53:00.610 --> 53:02.450]  I mean, internally, from Microsoft, as I hear.
[53:02.990 --> 53:04.690]  And from where you see from CVs,
[53:04.690 --> 53:08.250]  they follow CVs to Microsoft for critical stuff about SMB.
[53:09.230 --> 53:11.090]  And so I check it also.
[53:11.750 --> 53:14.310]  And it's hard to find now. I think non-authentication bugs
[53:15.050 --> 53:16.970]  will be a good lag, or
[53:17.810 --> 53:19.830]  that would be a good way to find it.
[53:20.190 --> 53:23.170]  But now, for example, authentication bugs
[53:23.170 --> 53:26.490]  are really also important, but it can be hard to find.
[53:27.530 --> 53:30.510]  And also, when you look in the windows,
[53:31.350 --> 53:32.970]  it's not about...
[53:32.970 --> 53:35.650]  you can find different things also in the kernel,
[53:35.650 --> 53:37.490]  because they introduced some new technologies.
[53:37.490 --> 53:39.930]  For example, Ubuntu on Windows, which is pretty nice,
[53:39.930 --> 53:42.230]  but it needs a whole new subsystem.
[53:42.830 --> 53:46.730]  And it depends on good facets, good reviews,
[53:46.730 --> 53:49.690]  it all depends. And maybe you can start looking at it,
[53:49.690 --> 53:51.650]  you can find more and more stuff.
[53:52.510 --> 53:55.710]  And you'll find, for example, SMB, MDP,
[53:55.710 --> 53:58.250]  and other things to look for.
[54:03.450 --> 54:05.030]  It's more and more challenging
[54:05.030 --> 54:06.710]  from the perspective of...
[54:06.710 --> 54:09.530]  you need to use more RAM to exploit something.
[54:09.890 --> 54:12.750]  And you have a lot of targets to exercise on.
[54:14.750 --> 54:16.650]  So, to think about the conclusions,
[54:17.410 --> 54:19.930]  the single most important thing about mitigation
[54:19.930 --> 54:21.810]  is attack-to-fat reduction.
[54:21.810 --> 54:24.290]  If you reduce me to... I can do nothing,
[54:24.290 --> 54:25.690]  then I just can do nothing.
[54:27.430 --> 54:29.970]  Then, sandboxing is very important.
[54:30.890 --> 54:33.690]  Because when you're living with only some small parts
[54:33.690 --> 54:36.750]  that I need to jump from one processor to another,
[54:36.750 --> 54:38.710]  I need to change multiple vulnerabilities.
[54:39.230 --> 54:42.310]  And that can be really annoying at this,
[54:42.310 --> 54:44.230]  and sometimes making it impossible.
[54:45.070 --> 54:46.850]  And it's also not difficult execution.
[54:46.910 --> 54:51.030]  I mean, it's public bypasses for them, usually.
[54:51.490 --> 54:54.530]  But still, for example, in the remote case,
[54:54.530 --> 54:56.550]  it can play a big role.
[54:56.910 --> 54:59.910]  And also in normal case, at least it will say,
[54:59.910 --> 55:03.130]  OK, but we need to bypass this one at first.
[55:03.530 --> 55:04.970]  Nobody will say that's impossible,
[55:04.970 --> 55:07.050]  but you will need to think about this one.
[55:07.330 --> 55:11.310]  So at least it's good. You can be more creative.
[55:11.950 --> 55:13.470]  Enjoy more, let's say.
